Current print architectures comprise a layered set of components. In particular, in the context of the WINDOWS operating system, applications carry out print-related requests (e.g., configuration, execution, status, etc.) by communicating such requests, in the form of WIN32 API commands, to the graphics device interface (GDI) and print spoolerof the operating system. The operating system (either directly or via a spooler), on behalf of the applications, passes the requests on to a printer driver associated with a particular installed printer.
The printer driver, associated with a particular installed printer type/personality, consists of dynamic-link libraries (DLLs) including a configuration/user interface module and a rendering module. The configuration/user interface module reports printer device capabilities and enables an application to obtain and designate values for configurable print parameters for a particular printer. The configuration/user interface module builds user interface related data for the application and enables a user to designate values for the configurable parameters. The configuration (e.g., settings) of a print job are stored within a known DEVMODE data structure. The printer driver handles the manipulation and validation of entries in the DEVMODE structure for the particular print job. When processing print requests initiated by an application, the rendering module generates raw device commands for submission to the printer device to render printed documents based upon the contents of the DEVMODE and a submitted input print file.
The printer drivers, in the known print architectures, stand alone with respect to other print drivers and print-related components in a system. Thus, for a set of six distinct printer types (personalities), six distinct printer drivers are installed on a computer system. It is noted that different printer devices can share a same driver. The printer drivers are provided in binary format and are generally neither editable nor extensible by users/administrators. Upgrading a previously installed printer driver is accomplished by replacing an old driver by a new one.
Under the current printer architecture, extending configurable features is limited to the device driver. The DEVMODE data structure, that provides information about print settings associated with a print job, is extended exclusively by the associated print driver. Thus, a DEVMODE cannot be extended to incorporate additional features supported by applications or print system components (other than the device driver).
Yet another characteristic of the printer driver-based print architectures is the existence of multiple print queues. In particular, a queue is maintained for each printer/personality combination. Thus, a separate queue is established for each personality of a multiple personality printer device. A result of this arrangement is the absence of a single user interface providing the status of all pending jobs to all printer/personality combinations to a multiple personality device.
The above described printer driver dominated printer architecture places a majority of the responsibility for printer code development in the hands of printer hardware providers. However, placing too much responsibility in the hands of the hardware providers has reduced the flexibility and extensibility of the base capabilities of the provided drivers. The known print system architecture inhibits uniformity in treating print features. The known print architectures potentially lead to duplicated/overlapping functionality provided by independent components of the existing print architecture.